…oss sessions, and `init()` loads every historical snapshot into memory on every hydration, because IndexedDB (unlike the former per-tab `sessionStorage`) persists across tab-close/restart with no cleanup path.

This commit fixes the issue reported at packages/kit/src/runtime/client/snapshot-storage.svelte.js:36

## Bug confirmed (still present)

`packages/kit/src/runtime/client/snapshot-storage.svelte.js` uses a shared, persistent IndexedDB store (`indexedDB.open(SNAPSHOT_KEY, 1)`) for snapshots but never scopes or prunes entries by browsing session. Because IndexedDB (unlike the former per‑tab `sessionStorage`) persists across tab‑close/restart:

* In `client.js` `start`, a fresh page load with no `history.state` sets `current_history_index = current_navigation_index = Date.now();`, so each session uses a **unique** numeric key base.
* `set(index, value)` → `put(index, value)` writes each captured snapshot keyed by that index. Snapshots may now contain large `File`/`Blob` objects.
* The only removal path is `truncate(index)`, which deletes forward‑history entries of the *current* session. Entries under previous sessions' unique `Date.now()`‑based keys never match a current index, so they are never deleted → **unbounded growth** and quota exhaustion risk.
* `init()` loads the **entire** store into the in‑memory `snapshots` map on every hydration, so startup cost grows monotonically.

The `efb62fc` sessionStorage fallback only added resiliency for when IndexedDB is *unavailable*; the normal path is unchanged, so the issue remains.

## Fix (reworked to use the Web Locks API)

The earlier `MAX_SESSIONS` last‑active‑timestamp heuristic was rejected as kludgy. This revision uses `navigator.locks` to determine which sessions are *actually* still alive, so there is no arbitrary retention count and no timestamp bookkeeping.

* **Session id** — generated once (`crypto.randomUUID()` with a non‑secure‑context fallback) and stored in `sessionStorage` under `SNAPSHOT_KEY:session` via the existing `storage` helper with identity parse/stringify. It survives reloads (so reload‑restore works) but is discarded when the tab closes.
* **Liveness lock** — the first time the session id is resolved, we fire‑and‑forget acquire an exclusive Web Lock `session:<id>` whose callback returns a promise that never resolves, so the lock is held for the tab's lifetime and released automatically by the browser on close/crash. The `request` promise is **not** awaited (it never settles); we only attach `.catch()` so a failed acquisition just leaves pruning conservative.
* **Compound keys** — snapshots are stored under `[session_id, index]`, so each entry is attributable to a session. The DB stays at **version 1** — the store has no `keyPath` (out‑of‑line keys), so switching from a plain number key to an array key needs no schema migration or second object store.
* **Pruning** — `init()` calls `navigator.locks.query()`, collects the ids of all held `session:*` locks into an `active` set that **always explicitly includes the current session** (guarding against `query()` running before this tab's own lock is granted), then iterates the store: loads only the current session's entries into memory, and deletes any entry whose session id isn't in `active` (this also removes legacy non‑namespaced number keys).
* **Graceful degradation** — `get_active_sessions()` returns `null` when `navigator.locks`/`query` is unavailable (older browsers / insecure context). In that case `init()` still loads only the current session's snapshots into memory but **does not prune** anything, since staleness can't be proven — we never delete data we can't confirm is dead.
* **Fallback intact** — the `efb62fc` sessionStorage fallback (`init()` catch, `set()`, `truncate()`) and the `import * as storage from './session-storage.js'` alias are reused unchanged.

### Residual edge case

A tab that is mid‑startup and hasn't yet been granted its `session:*` lock could, in principle, have its snapshots pruned by another tab's concurrent `init()`. This is acceptable in practice: a fresh session rarely has persisted snapshots yet, and its id is always included in its own `active` set, so it never prunes itself.

Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: Rich-Harris <hello@rich-harris.dev>

Co-authored-by: Tee Ming <chewteeming01@gmail.com>